Chapitre 10 [edition] Tester, reporter les bugs, valider

Lorsque les [ChfDev] sont satisfaits des avancées et souhaitent passer en phase de validation, une nouvelle version voit le jour. Plusieurs versions intermédiaires peuvent voir le jour avant la version finale espérée. Ces phases intermédiaires permettent de fermer des tickets, et donc de libérer la colonne “A valider” du Kanban.

10.1 Phase de validation

Le produit et son utilisation sont testés par les [Ed].

  • Informer les [Ed] qu’une phase de validation commence en asynchrone
  • Les [Ed] suivent le guide d’utilisation du projet et les consignes dans les différents tickets A valider
  • Les [Ed] ajoutent un message dans les tickets appropriés pour indiquer si tout est réglé ou non, lorsque c’est possible.
  • Les [Ed] ouvrent des nouveaux tickets si besoin
  • Les [ChfDev] décident du sort des tickets : fermer, développer un patch ou reléguer pour une version suivante (et prioriser).
  • Des échanges en asynchrone sur le logiciel de Chat permettent d’aborder les problèmes opérationnels (Je ne trouve pas le fichier, je ne sais plus où regarder, ma version n’est pas à jour, …)
  • Une réunion en synchrone peut permettre de valider certains tickets en direct. En particulier lorsqu’il s’agit de discuter sur des choses visuelles.

10.2 Valider les tickets

Vous l’avez vu dans la section “Suivre le traitement de ses besoins”, deux colonnes du Kanban vous concernent. Dans le cas de la phase de validation, c’est sur la colonne A valider que vous allez travailler.

  • Répartissez les tickets à valider entre les [Rel]
  • Suivre les consignes du guide d’utilisation du projet
  • Reportez toutes les difficultés et les problèmes potentiels avec un commentaire dans la page du ticket que vous validez
    • N’hésitez pas à joindre des captures d’écran au besoin dans votre commentaire
  • Laissez le message “Validé : Ce ticket peut être fermé” lorsque tout est bon

10.3 Reporter des bugs

Lors de votre phase d’exploration, vous rencontrerez peut-être des problèmes qui ne sont pas en lien avec le ticket que vous validez.

  • Vérifier s’il n’y a pas déjà un ticket ouvert à ce sujet dans la liste des tickets.
  • Vérifier que vous êtes en train de tester la dernière version disponible
  • Ouvrir un nouveau ticket.
    • Mettre un titre explicite
    • Indiquer la version du projet sur laquelle vous êtes
    • Décrire le problème
    • Indiquer le fonctionnement attendu
    • Décrire comment vous en êtes arrivés là
    • Décrire ce que vous avez testé
    • Ajouter des captures d’écran au besoin
  • Indiquer dans le Chat les tickets que vous avez ouverts
  • Selon le problème, vous pouvez vous-même participer à la correction, en proposant une Merge Request
    • Directement avec l’interface GitLab pour une proposition de modification mineure (Ouvrir le fichier > Edit > Créer commit dans une branche)
    • En récupérant le projet en local et en suivant les instructions de “Collaboration avec git et RStudio”

10.4 Demander de nouvelles fonctionnalités

Les demandes de nouvelles fonctionnalités doivent repasser par la phase de définition des besoins. Commencer par vérifier que votre demande ne fait pas déjà partie de la trame de publication prévue.